クラスメソッドで全エンジニアがブログ書きまくる秘訣とは？ #DevReljp

「なぜ、クラスメソッドは全エンジニアがブログを書きまくるのか？」という謎に対して、入社1年の1エンジニアが思うところをぶちまけてみました。

#イベント

#勉強会

濱田孝治

2018.10.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

マーケ部長：「ハマちゃん、ツイ廃やんな？」

ハマコー：「まぁ、人並みには…」

マーケ部長：「じゃ、ソーシャル活用テーマでなんか喋って」

ハマコー：「（でたよ、この会社）」

というわけで、下記勉強会にてソーシャル活用について喋ってきました。

DevRel Meetup in Tokyo #35 〜ソーシャル〜 - connpass

一エンジニアの自分は、マーケティング素養皆無
twitterのつぶやきに戦略性は皆無
すいません。DevRelって、初めて聞きました
ウチの会社って、ブログは有名やけど、ソーシャルとかなんかあったっけ？
てか、これ、スーツの人の集まりやんな？俺が喋っても、むっちゃ浮く気がするけど！？

悶々とした気持ちを抱えながら当日参加してきたんですが、参加者スーツっぽい人は皆無で、エンジニアの人も非常に多く、ハッシュタグつぶやきも300超という、なんせとっても楽しい勉強会でした。

（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     DevRelﾏﾂﾘﾀﾞﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

登壇内容「全エンジニアDevRelな組織におけるソーシャル活用方法」

クラスメソッドにおけるDevRelとは

本日、端的にお伝えしたいことはこちらです。

DevRel（Developer Relation）の一般的な定義ってこんな感じだと思います。

クラスメソッドのDevRelは、言ってしまえばこんな感じです。

DevRelには、エンジニア全員が参加していて、その量は圧倒的です。頭おかしいレベルです。その中核と成るのがブログですが、クラスメソッドにおけるDevRelをイメージにするとこうなります。

これが、圧倒的な物量と圧倒的な速度で回っているのが、クラスメソッドの最大の特色じゃないでしょうか。なんでこんなもんが回っているのかと言うと、会社の仕組みとして、これを円滑に回すための仕組みや文化が有るからなんですね。

エンジニア全員がDevRelに携わる秘訣

自分はまだ入社1年ぐらいのペーペーですが、このサイクルにどっぷりハマっている1エンジニアの視点から、「クラスメソッドにおいて、全エンジニアDevRelが回る秘訣」を考えてみました。

秘訣①「評価制度にブログが組み込まれている」

これは、そのまんま人事考課にブログ本数が組み込まれているということです。いくら「アウトプットが大事やで！」と言ってても、評価されないとしたらエンジニア目線で不信感溜まりますもんね。まずはベースとして、この部分は確立したほうが良いかと思います。

秘訣②「社内レビューが一切ない」

これ、自分がこの会社入って一番衝撃だったんですが、まじでブログでも登壇するときの発表内容も事前の上司レビューが一切ありません。もちろん、お願いしたら必ず誰かがレビューはしてくれるんですが、事前の必須レビューは一切ないです。

何か外にアウトプットしようとしたとき、過剰な上司レビューが入る体制だと、どうしても「上司のレビューを抜けること」に意識がいくんですね。そういう体制になっていると、「何か書こう」と思ったときに、レビューが気になって「やっぱ止めた」となりがちなんですよ。これは情報発信の体制として健全じゃないと。

結局は会社とエンジニアの間にある信頼感だと思います。エンジニアが「書きたい」と思ったときになんでも書いて良い会社としての姿勢が、この「事前レビュー一切なし」に出ているんじゃないでしょうか。

「公序良俗に反する内容を誰かが公開したらどうするの？」とかね、そういうの杞憂です。無いです。ただ、「こういう記事の書き方はやめよう」というガイドラインは存在します。弊社のガイドラインを一部紹介します。

ブログに書いてはいけないガイドライン
- 対象サービスをディスる表現
- 非公開ベータ版などの情報
- 個人情報がのった情報（スクショなどは要注意）
- ネットの噂ベースの情報
- 事実誤認やサービス規約違反を推奨する内容
- コピペや引用の範囲を越えた転載
- 特定団体や個人の誹謗中傷

技術ブログで情報発信を考えている組織は、是非このあたり参考にしていただければと思います。

秘訣③「ソーシャルフィードバックが可視化されている」

「ソーシャルフィードバック　→　承認欲求」

各記事には、シェア数をベースとしたポイントがあります。シェア数が一定数以上あがってくると、記事にリボンがつくんですね。でこれが、どんどん派手になってくると。こまい仕組みなんですが、実際これでモチベーションあがります。なぜか上がります。

各エンジニアのプロフィール欄には、こういった経験値が表示されていたりもします。これ、自分のプロフィールページです。

濱田孝治｜ DevelopersIO

また、全社の四半期報告会ごとに、SNSシェア、PV、本数でランキングされ、トップの人は表彰されたりというのもやってます。

まとめ

以上、全エンジニアが情報発信者（DevRel）なクラスメソッド式、ソーシャル活用でした。

登壇資料

登壇後日談

当日の勉強会の様子は、togetterにまとめられています。まとめ人が、なんとtogetterの社長（yositosiさん）！！という豪華まとめ。ワチャワチャした感じが伝わるかと。

企業のソーシャル活用ノウハウ、公式アカウント運用からTwitter拡散のお話 DevRel Meetup in Tokyo #35 〜ソーシャル〜ツイートまとめ #devreljp - Togetter

同じく登壇されていたのが、戸倉彩さん、yositosi(@yositosi)さんというビッグネームで、正直登壇前は「自分、なにしゃべるんだこれ…」と日和ってたんですが、参加いただいた方にクラスメソッドの雰囲気が伝わったようで嬉しかったです。全部は紹介しきれませんが、ハッシュタグでも嬉しい反応いろいろいただきました。